Repository navigation
computer: Make the codemode module scheme configurable - #323
Conversation
CodemodeBackend serves host modules, and the libraries a host provides, only under codemode:*. A host that presents these modules to a model as its own, such as agent:git and agent:web, has no way to name them so. The backend now takes scheme, which replaces codemode everywhere the scheme was fixed: the specifiers host modules and host libraries must use, the imports a source module may make by name, the error for code that imports an unconfigured module under the scheme, and the module names reserved for Workspace internals. Under another scheme, codemode:* is an ordinary bare name. The scheme is checked when the backend is constructed: a lowercase letter followed by lowercase letters, digits, or dashes, and not one the Workers runtime or URLs already give a meaning, such as node or https. It defaults to codemode, and a backend without the option behaves as before. createBrowserModule() names its own specifier and codemode:tools in the description it gives the model, so it takes specifier and toolsSpecifier for a host that serves the browser or the agent's tools under other names. Its errors name its specifier too.
🦋 Changeset detectedLatest commit: b9b2004 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| for (const site of sites) { | ||
| const imported = site.specifier; | ||
| if (imported.startsWith("codemode:")) { | ||
| if (imported.startsWith(`${scheme}:`)) { |
There was a problem hiding this comment.
🟡 Cross-scheme library imports fail
With scheme: "agent", prepareSourceModules leaves imports of configured codemode:* libraries unchanged. The Loader treats these names as URLs, while buildModuleGraph stores the libraries under __modules__/. Executions importing them from another configured library fail to load.
Learn more
The backend permits a configured source library outside its selected scheme and rewrites caller imports to the module directory. A configured source library that imports that library by name passes preparation unchanged unless the imported name begins with the selected scheme. The Loader treats colon-bearing names as URLs, not as paths to the module directory, so loading the graph fails. buildModuleGraph places every configured library in that directory.
Example: Configure scheme: "agent" with "codemode:lib": "export const value = 1" and "agent:facade": "import { value } from 'codemode:lib'; export { value }". A run importing agent:facade cannot load its codemode:lib dependency, even though both libraries are configured.
Recommended fix: In prepareSourceModules, rewrite imports of all configured source names to relative module-directory paths, including names with a different scheme. Preserve the existing missing-module check for imports under the selected scheme, and test a source-to-source import across schemes.
Was this helpful? React with 👍 or 👎 to provide feedback.
| * `-`, and not one the Workers runtime or URLs already use, such as | ||
| * `node`, `cloudflare`, `http` or `file`. | ||
| */ | ||
| scheme?: string; |
There was a problem hiding this comment.
🟡 New scheme has no consumer example
Adding scheme changes the public backend API, but no runnable example uses it. The repository requires examples to accompany public API changes, leaving custom module names unexercised in a consumer.
Learn more
The repository's agent guidelines require updating examples when a public API changes. scheme is a new public backend option, and createBrowserModule also gains public naming options. The existing codemode example still uses the default backend with no modules; none of the runnable consumers demonstrate the new configuration.
Example: A user following the codemode example sees no working configuration for scheme: "agent" or for importing agent:git from code, despite the new public option.
Recommended fix: Add a runnable consumer example that configures a custom scheme, registers a matching host module, and imports it; include browser specifiers if the consumer uses the browser module.
Was this helpful? React with 👍 or 👎 to provide feedback.
commit: |
CodemodeBackend serves host modules, and the libraries a host provides,
only under codemode:*. A host that presents these modules to a model as
its own, such as agent:git and agent:web, has no way to name them so.
The backend now takes scheme, which replaces codemode everywhere
the scheme was fixed: the specifiers host modules and host libraries
must use, the imports a source module may make by name, the error for
code that imports an unconfigured module under the scheme, and the
module names reserved for Workspace internals. Under another scheme,
codemode:* is an ordinary bare name. The scheme is checked when the
backend is constructed: a lowercase letter followed by lowercase
letters, digits, or dashes, and not one the Workers runtime or URLs
already give a meaning, such as node or https. It defaults to codemode,
and a backend without the option behaves as before.
createBrowserModule() names its own specifier and codemode:tools in the
description it gives the model, so it takes specifier and
toolsSpecifier for a host that serves the browser or the agent's tools
under other names. Its errors name its specifier too.